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ABSTRACT 

As  embedded  systems  increase  in  complexity  and  begin  to  partic¬ 
ipate  in  distributed  systems,  the  need  for  middleware  in  building 
such  systems  becomes  imperative.  However,  the  use  of  middle¬ 
ware  that  fully  implements  such  standards  can  impose  a  significant 
increase  in  footprint  for  an  application,  making  it  unsuitable  for  use 
in  embedded  systems.  We  consider  the  use  of  a  standard  CORBA 
event  channel  in  a  setting  where  distribution  and  inter-language 
support  are  unnecessary.  We  report  our  experience  in  applying  as¬ 
pects  to  abstract  the  transport  layer  (CORBA)  of  the  event  channel 
into  a  selectable  feature.  Thus,  enabling  or  disabling  CORBA  for  a 
specific  application  can  be  decided  at  build-time,  by  merely  select¬ 
ing  CORBA  as  a  feature.  We  describe  the  patterns  used  to  achieve 
this  abstraction  and  present  footprint  and  throughput  results  show¬ 
ing  the  effect  of  CORBA  on  automatically  derived  subsets  of  the 
event  channel. 

Categories  and  Subject  Descriptors 

C. 2.4  [Computer-Communication  Networks]:  Distributed  Sys¬ 
tems;  C.3  [Computer  Systems  Organization]:  Special-Purpose 
and  Application-Based  Systems — Real-time  and  embedded  systems; 

D. l.m  [Programming Techniques]:  Miscellaneous 

*This  work  was  sponsored  by  the  DARPA  Information  Exploitation 
Office  Program  Composition  for  Embedded  Software  program  un¬ 
der  contracts  F33615-00-C-1697  and  F33615-00-C-3048,  admin¬ 
istered  by  the  Air  Force  Research  Laboratory  (AFRL)  Real-Time 
Java  for  Embedded  Systems  program,  Wright-Patterson  Air  Force 
Base  (WPAFB),  Information  Directorate,  under  contract  F33615- 
97-D-1155. 
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Algorithms,  Design,  Experimentation,  Performance 

Keywords 

AOP,  CORBA,  middleware,  embedded  systems,  subsetting,  event 
service,  software  composition,  transport  abstraction 

1.  INTRODUCTION 

Distributed  systems  have  relied  on  common  interfaces  to  achieve 
a  high-degree  of  inter-operability,  reliability  and  reusability.  The 
emergence  of  standards  such  as  the  Common  Object  Request  Bro¬ 
ker  Architecture  (CORBA)  [20]  and  DCOM  [18]  and  their  wide 
spread  use  in  building  applications  continues  to  underscore  the  im¬ 
portance  of  relying  on  such  interfaces.  As  embedded  systems  are 
deployed  in  new  scenarios  such  as  distributed  systems,  the  need  to 
interact  with  and  make  use  of  existing  standards  is  imperative.  By 
using  established  communication  standards  between  systems,  it  is 
possible  to  build  effective  and  reusable  embedded  system  compo¬ 
nents. 

An  Event  Channel  is  a  well-established,  standard  interface  for 
decoupling  the  supplier  and  consumer  of  events  in  a  distributed 
system  [22]  [29].  Event  Channels  can  be  made  customizable  us¬ 
ing  compositional  approaches,  such  as  feature  specification  using 
Aspect-Oriented  Programming  (AOP)  [15]  [16],  The  footprint 
in  such  cases  can  be  half  of  that  required  for  a  full-featured  event 
channel  when  measurements  exclude  the  size  of  the  supporting  Ob¬ 
ject  Request  Broker  (ORB).  However,  what  is  of  importance  to  an 
embedded  application  is  the  combined  footprint  of  the  event  chan¬ 
nel  as  well  as  the  ORB.  The  footprint  of  a  high-quality  Event  Ser¬ 
vice  implementation  such  as  the  ADAPTIVE  Communication  En¬ 
vironment  (ACE)  ORB  (TAO)  Event  Service  in  certain  configura¬ 
tions  can  be  quite  high  mostly  due  to  the  size  of  the  ORB  [14]. 
Clearly,  The  ACE  ORB  (TAO)’s  footprint  is  the  key  concern  for 
small-footprint  event  channels  which  need  to  be  deployed  in  em¬ 
bedded  systems  with  tight  constraints  and  limited  resources.  While 
efforts  are  underway  to  create  reduced-feature,  small-footprint  ORBs 
[9],  there  are  compelling  applications  that  do  not  need  one  or  more 
of  the  following:  distribution,  inter-language  support  and  real-time 
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guarantees. 

This  paper  describes  an  application  of  aspect  and  component  ori¬ 
ented  programming  techniques  to  an  Event  Service  to  concretely 
demonstrate  and  measure  its  benefits  in  one  particular  application. 
As  such,  however,  it  also  provides  evidence  for  the  efficacy  of  ap¬ 
plying  these  techniques  to  middleware  for  the  more  general  class 
of  distributed  Real-Time  Embedded  Systems  (RTES).  We  report 
on  the  experience  of  deploying  an  AOP-customized  Event  Chan¬ 
nel,  where  the  aspects  also  govern  the  use  of  CORBA  and  conse¬ 
quently,  the  inclusion  or  exclusion  of  an  ORB.  The  resulting  Event 
Channel  has  been  used  in  a  Real-Time  Specification  for  Java^^ 
(RTSJ)  setting  for  prototyping  avionics  middleware  [26]. 

Our  paper  is  organized  as  follows:  Section  2  provides  a  brief 
overview  of  CORBA.  Section  3  describes  some  of  the  motivation 
behind  the  need  for  developing  flexible  middleware.  Section  4  de¬ 
scribes  current  approaches  to  subsetting  middleware  such  as  event 
channels.  Section  5  describes  the  architecture  of  the  Framework 
for  Aspect  Composition  for  an  EvenT  channel  (FACET)  that  we 
have  built  using  AOP  techniques  and  describes  the  challenges  in 
abstracting  the  transport  layer  and  the  patterns  used  to  solve  them. 
Section  6  quantifies  the  benefits  of  our  approach.  Finally,  Section  7 
describes  our  planned  future  work  applying  aspects  to  flexible  mid¬ 
dleware  components  and  services. 

2.  BACKGROUND 

In  this  section,  we  give  a  brief  overview  of  the  CORBA  refer¬ 
ence  model  so  as  to  provide  a  context  for  the  work  presented  in 
subsequent  sections, 

2.1  Overview  of  the  CORBA  ORB  Reference 
Model 

CORBA  Object  Request  Brokers  (ORBs)  allow  clients  to  invoke 
operations  on  distributed  objects  without  concern  for  object  loca- 
tion,  programming  language,  OS  platform,  communication  proto¬ 
cols  and  interconnects,  and  hardware  [13].  Figure  I  illustrates  the 
key  components  in  the  CORBA  reference  model  [21]  that  collabo¬ 
rate  to  provide  this  degree  of  portability,  interoperability,  and  trans¬ 
parency.  ' 

CORBA  ORBs  [20]  allow  clients  to  invoke  operations  on  dis¬ 
tributed  objects  without  concern  for  the  following  issues: 

•  Object  location:  CORBA  objects  either  can  be  collocated 
with  the  client  or  distributed  on  a  remote  server,  without  af¬ 
fecting  their  implementation  or  use. 

•  Programming  language:  The  languages  supported  by  CORBA 
include  C,  C++,  Java  COBOL,  and  Smalltalk,  among  oth¬ 
ers. 

•  OS  platform:  CORBA  runs  on  many  OS  platforms,  including 
Win32,  UNIX,  MVS,  and  real-time  embedded  systems  like 
Vx Works,  Chorus,  and  LynxOS. 

•  Communication  protocols  and  interconnects:  The  communi¬ 
cation  protocols  and  interconnects  that  CORBA  run  on  in¬ 
clude  TCP/IP,  IPX/SPX,  FDDI,  ATM,  Ethernet,  Fast  Ether¬ 
net,  embedded  system  backplanes,  and  shared  memory. 

•  Hardware:  CORBA  shields  applications  from  side  effects 
stemming  from  differences  in  hardware,  such  as  storage  lay¬ 
out  and  data  type  sizes/ranges. 

^This  overview  only  focuses  on  the  CORBA  components  relevant 
to  this  paper.  For  a  complete  synopsis  of  CORBA  *s  components 
see  [20]. 

^Java  is  a  trademark  of  Sun  Microsystems,  Inc. 


Figure  1  illustrates  the  components  in  the  CORBA  2.x  reference 
model,  all  of  which  collaborate  to  provide  the  portability,  interop¬ 
erability  and  transparency  outlined  above. 
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Figure  1:  Components  in  the  CORBA  2.x  Reference  Model 

Each  component  in  the  CORBA  reference  model  is  outlined  be¬ 
low: 


•  Client:  A  client  is  a  role  that  obtains  references  to  objects 
and  invokes  operations  on  them  to  perform  application  tasks. 
A  client  has  no  knowledge  of  the  implementation  of  the  ob¬ 
ject  but  does  know  its  logical  structure  according  to  its  inter¬ 
face.  It  also  doesn’t  know  of  the  object’s  location  -  objects 
can  be  remote  or  collocated  relative  to  the  client.  Ideally,  a 
client  can  access  a  remote  object  just  like  a  loca!  object,  Fig¬ 
ure  1  shows  how  the  underlying  ORB  components  described 
below  transmit  remote  operation  requests  transparently  from 
client  to  object. 

•  Object:  In  CORBA,  an  object  is  an  instance  of  an  Object 
Management  Group  (OMG)  Interface  Definition  Language 
(IDL)  interface.  Each  object  is  identified  by  an  object  ref¬ 
erence^  which  associates  one  or  more  paths  through  which 
a  client  can  access  an  object  on  a  server.  An  object  ID  as¬ 
sociates  an  object  with  its  implementation,  called  a  servant, 
and  is  unique  within  the  scope  of  an  Object  Adapter.  Over  its 
lifetime,  an  object  has  one  or  more  servants  associated  with 
it  that  implement  its  interface. 

•  Servant:  This  component  implements  the  operations  defined 
by  an  OMG  IDL  interface.  In  object-oriented  (00)  lan¬ 
guages,  such  as  C++  and  Java,  servants  are  implemented  us¬ 
ing  one  or  more  class  instances.  In  non-OO  languages,  such 
as  C,  servants  are  typically  implemented  using  functions  and 
structs.  A  client  never  interacts  with  servants  directly,  but 
always  through  objects  identified  by  object  references. 

•  ORB  Core:  When  a  client  invokes  an  operation  on  an  ob¬ 
ject,  the  ORB  Core  is  responsible  for  delivering  the  request 
to  the  object  and  returning  a  response,  if  any,  to  the  client. 
An  ORB  Core  is  implemented  as  a  run-time  library  linked 
into  client  and  server  applications.  For  objects  executing  re¬ 
motely,  a  CORBA-compliant  ORB  Core  communicates  via 
a  version  of  the  General  Inter-ORB  Protocol  (GIOP),  such 
as  the  Internet  Inter-ORB  Protocol  (HOP)  that  runs  atop  the 
TCP  transport  protocol. 
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•  ORB  Interface:  An  ORB  is  an  abstraction  that  can  be  im¬ 
plemented  various  ways,  e.g.,  one  or  more  processes  or  a  set 
of  libraries.  To  decouple  applications  from  implementation 
details,  the  CORBA  specification  defines  an  interface  to  an 
ORB.  This  ORB  interface  provides  standard  operations  to 
initialize  and  shut  down  the  ORB,  convert  object  references 
to  strings  and  back,  and  so  on. 

•  IDL  Stubs  and  Skeletons:  IDL  stubs  and  skeletons  serve  as 
a  “glue”  between  the  client  and  servants,  respectively,  and 

.  the  ORB.  Stubs  implement  the  Proxy  pattern  [8]  and  marshal 
application  parameters  into  a  common  message-level  repre¬ 
sentation.  Conversely,  skeletons  implement  the  Adapter  pat¬ 
tern  [8]  and  demarshal  the  message-level  representation  back 
into  typed  parameters  that  are  meaningful  to  an  application. 

•  IDL  Compiler:  An  IDL  compiler  transforms  OMG  IDL  def¬ 
initions  into  stubs  and  skeletons  that  are  generated  automati¬ 
cally  in  an  application  programming  language,  such  as  C++ 
or  Java.  In  addition  to  providing  programming  language  trans¬ 
parency,  IDL  compilers  eliminate  common  sources  of  net¬ 
work  programming  errors  and  provide  opportunities  for  au¬ 
tomated  compiler  optimizations  [6]. 

•  Object  Adapter:  An  Object  Adapter  is  a  composite  com¬ 
ponent  that  associates  servants  with  objects,  creates  object 
references,  demultiplexes  incoming  requests  to  servants,  and 
collaborates  with  the  IDL  skeleton  to  dispatch  the  appropri¬ 
ate  operation  upcall  on  a  servant.  Even  though  different  types 
of  Object  Adapters  may  be  used  by  an  ORB,  the  only  Object 
Adapter  defined  in  the  CORBA  specification  is  the  Portable 
Object  Adapter  (POA). 

3.  MOTIVATION 

One  of  the  special  challenges  associated  with  embedded  systems 
is  supporting  their  great  diversity.  Even  within  the  very  closely 
related  set  of  avionics  systems  associated  with  the  Boeing  Bold 
Stroke  product  line  software  initiative,  systems  may  have  anywhere 
from  one  to  ten  processors,  may  run  on  Versa  Module  Europe  (VME) 
and/or  fiber  channel  based  interconnects,  may  have  one  or  more 
languages,  and  may  run  on  a  range  of  different  operating  systems. 
When  these  characteristics  are  taken  together,  the  simplest  deployed 
systems  are  single  processor  applications  written  completely  in  C++ 
without  any  interprocess  communication,  and  the  most  complex 
ones  are  multiple  VME  backplanes  connected  by  fiber  channel, 
each  with  multiple  processors,  also  written  entirely  in  C++.  There 
are  also  mixed  C++  and  Ada-based  distributed  systems.  All  of 
these  are  real-world  systems,  deployed  in  practice. 

Even  within  a  single  product,  embedded  systems  often  impose 
significant  resource  constraints.  Resource  constraints  may  stem 
from  limitations  on  size,  weight,  power,  cost,  aging  hardware  or 
other  factors.  Small  consumer-devices  such  as  cell  phones  and 
hearing  aids  emphasize  size,  weight,  power,  and  cost  factors.  Larger, 
mass-produced  systems  such  as  automotive  electronics  are  more  fo¬ 
cused  on  cost.  More  complex  systems  such  as  avionics  are  expected 
to  be  operational  for  a  long  life  due  to  their  expense. 

Developing  a  single  framework  and  implementation  software  that 
can  be  reused  across  a  range  of  products  as  in  Bold  Stroke  how¬ 
ever,  poses  significant  additional  challenges,  A  component-based 
application  architecture  was  created  to  provide  a  configurable  and 
composable  application  capability  [26].  ACE  [24],  TAO  [4]  and 
other  architecture-specific  services  were  created  to  provide  a  stable 
foundation  for  these  applications  [5].  This  middleware  foundation 
is  also  highly  configurable,  but  does  not  provide  the  same  level  of 


component-based  granularity  provided  in  the  application.  Further¬ 
more,  while  the  extensive  use  of  compiler  directives  and  macros, 
for  instance,  does  provide  a  single  code  base  for  reuse  across  a 
wide  range  of  platforms,  the  necessary  scattering  and  tangling  of 
the  code  needed  for  all  of  the  variants  can  significantly  obscure 
the  code  associated  with  one  particular  use.  The  limitations  of  this 
approach  in  providing  middleware  implementations  that  scale  to 
meet  the  required  featui;e  set  for  a  particular  system  without  incur¬ 
ring  overhead  associated  with  unused  features  has  led  to  substantial 
interest  in  production  programs  in  component-oriented  and  aspect- 
oriented  approaches  to  middleware. 

Colleagues  at  the  University  of  British  Columbia  on  the  Program 
Composition  for  Embedded  Software  (PCES)  program  have  also 
shown  how  AOP  approaches  can  alleviate  some  of  the  configurabil¬ 
ity  limitations  in  the  component  based  application  for  cases  where 
customizations  are  inherently  scattered  and  tangled  with  the  base¬ 
line  code. 

Real-time  developers  are  typically  reluctant  to  adopt  new  tech¬ 
nologies  —  including  C,  C++,  and  CORBA  —  because  those  tech¬ 
nologies  often  ignore  the  needs  of  real-time  systems.  The  use  of 
Java  in  real-time  applications  is  thus  relatively  new.  While  the  use 
of  Java  as  the  sole  language  in  large-scale  real-time  applications  is 
unlikely  fn  the  near-term,  efforts  such  as  ours  are  focused  on  laying 
the  foundation  for  such  applications  in  the  future. 

4.  RELATED  WORK 

The  need  to  subset  (or  extend)  middleware  selectively  has  ex¬ 
isted  for  some  time.  Before  the  emergence  of  AOP  techniques 
to  separate  concerns,  subsetting  techniques  made  use  of  object- 
oriented  patterns.  In  previous  work,  AOP  techniques  haVe  been 
used  to  demonstrate  a  high  degree  of  feature  control  and  conse¬ 
quently,  footprint  management  [15]  [16]  [14].  However,  such  work 
has  not  concentrated  on  abstracting  the  transport  layer  as  a  feature 
so  as  to  allow  an  even  greater  level  of  customizability  for  a  specific 
application.  In  the  following,  we  provide  some  background  to  our 
use  of  AOP  in  doing  transport  layer  abstraction  in  FACET. 

4.1  Object-Oriented  Subsetting  Techniques 

Developing  middleware  to  be  flexible  in  diverse  environments 
often  involves  the  following  process  [16]: 

1 .  Building  flexibility  and  extensibility  around  known  variation 
points  at  the  beginning. 

2.  Refactoring  functionality  out  of  the  core  middleware  to  ex¬ 
tensions  and  adding  flexibility  as  new  features  are  added  and 
as  the  footprint  becomes  too  large. 

Unfortunately,  the  first  relies  on  a  designer’s  ability  to  precon¬ 
ceive  feature  extension  points.  As  this  is  impractical  with  all  but 
the  smallest  frameworks,  functionality  inevitably  gets  added  that 
will  need  to  be  refactored  to  extensions  later.  Quite  a  few  object- 
oriented  design  patterns  have  been  identified  that  document  suc¬ 
cessful  strategies  to  subsetting  middleware.  These  include  pat¬ 
terns  such  as  Strategy  [8],  Interceptors,  Extension  Interface,  Ser¬ 
vice  Configurator  and  others  [25].  Although  such  patterns  have 
been  used  extensively  in  middleware  such  as  ACE  [24]  and  TAO  [4], 
these  come  with  some  limitations: 

1 .  They  require  additional  infrastructure  within  the  framework 
to  support  their  presence.  For  example.  Strategy  and  Inter¬ 
ceptors  require  method  invocation  hooks  to  be  placed  at  key 
locations  throughout  the  code.  From  a  programmer  stand¬ 
point,  these  hooks  and  the  additional  infrastructure  lessen  the 
readability  and  maintainability  of  the  code. 
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2.  If  the  locations  where  subsetting  should  have  occurred  are 
not  preconceived,  time  consuming  refactoring  may  be  needed 
to  extract  functionality  into  separate  libraries. 

3.  The  hooks  and  infrastructure  themselves  can  lead  to  degra¬ 
dations  in  performance  and  increase  in  footprint  size  if  some 
or  all  of  them  are  not  used, 

4.2  Separation  of  Concerns  using  AspectJ 

AOP  [17]  is  a  software  development  paradigm  that  enables  one 
to  separate  concerns  that  crosscut  sets  of  classes  and  encapsulate 
those  concerns  in  self-contained  modules  called  aspects.  The  As¬ 
pect!  [28]  programming  language  adds  AOP  constructs  to  Java  [2] 
and  uses  the  following  terminology.  Within  an  aspect,  the  loca¬ 
tions  at  which  code  should  be  applied  are  defined  \xsmg  pointcuts. 
Each  pointcut  is  made  up  of  one  or  more  joinpoints^  which  are  well- 
defined  points  in  the  execution  of  a  program.  The  code  applied  at  a 
pointcut  is  called  advice.  In  addition  to  applying  advice,  languages 
supporting  AOP  often  allow  new  methods  or  other  language  fea¬ 
tures  to  be  introduced  into  existing  classes.  It  is  also  possible  to 
change  the  inheritance  hierarchy  of  a  class  by  changing  the  list  of 
interfaces  it  implements  or  the  classes  it  derives  from. 

In  previous  work  [15]  [16],  this  powerful,  new  programming 
paradigm  has  been  applied  to  build  software  using  the  composi¬ 
tional  approach  by  building  a  core  of  basic  functionality  and  then 
codifying  all  additional  features  into  separate  aspects.  Since  the 
transport  layer  used  in  the  event  delivery  mechanism  is  a  cross¬ 
cutting  concern  for  the  set  of  classes  implementing  the  functional¬ 
ity  of  the  event  channel,  it  would  be  possible  to  abstract  this  into 
a  separate  aspect  such  that  the  inclusion  or  exclusion  of  the  same 
produces  an  event  channel  with  the  desired  functionality. 

5.  IMPLEMENTATION 

In  this  section,  we  describe  our  AOP  approach  for  compositional 
construction  of  an  event  channel.  We  focus  only  on  the  particulars 
of  our  implementation  that  are  relevant  to  the  transport  layer  and 
its  abstraction.  We  omit  details  concerning  other  features,  perfor¬ 
mance  of  those  features,  and  our  testing  framework  [15]  [16]  [14]. 

5.1  Architecture  of  FACET 

FACET  is  an  implementation  of  a  CORBA  [20]  event  channel 
that  uses  AOP  to  achieve  a  high  level  of  customizability.  Its  func¬ 
tionality  is  based  on  features  found  in  the  OMG  Event  Service  [22], 
the  OMG  Notification  Service  [19]  [11],  and  the  TAO  Real-time 
Event  Service  [23]  [12]. 

An  event  channel  is  a  common  middleware  framework  that  de¬ 
couples  event  suppliers  and  consumers.  The  event  channel  acts  as  a 
mediator  through  which  all  events  are  transported.  Figure  2  shows 
the  main  participants  in  an  event-channel  framework.  At  its  sim¬ 
plest, 

•  Suppliers  push  events  to  the  event  channel 

•  The  event  channel  applies  any  filtering,  correlation  or  other 
specified  features  to  the  events 

•  The  event  channel  pushes  appropriate  events  to  consumers. 

Event  channel  implementations  differ  in  the  types  of  events  that 
they  handle  and  in  the  processing  and  forwarding  that  occurs  within 
the  channel. 

FACET  is  separated  into  a  base  and  a  set  of  selectable  features. 
The  base  represents  a  fundamental  and  indivisible  level  of  function¬ 
ality.  Each  feature  adds  a  structural  and/or  functional  enhancement 


Figure  2:  Main  participants  in  an  event  channel. 

to  the  base.  Moreover,  a  feature  can  affect  the  structure  and  func¬ 
tion  of  other  features.  AOP  language  constructs  are  then  used  to 
integrate  or  to  weave  feature  code  into  the  appropriate  places  in  the 
base  and  selected  features. 

The  construction  of  FACET  follows  a  bottom-up  approach  in 
which  features  are  implemented  as  needed.  As  new  requirements 
are  presented,  they  are  decomposed  into  one  or  more  features.  In 
the  case  of  FACET,  the  features  of  several  existing  event  services 
were  selected  one-by-one  for  incorporation.  By  using  AOP  tech¬ 
niques,  the  code  for  each  of  these  features  can  then  be  weaved  into 
the  base  at  the  appropriate  points. 

5.1.0.}  Lackof  Transport  Abstraction. 

FACET  was  originally  designed  to  use  CORBA  so  that  events 
can  be  sent  to  and  received  from  remote  consumers  and  suppliers. 
The  advantages  of  CORBA  include  the  ability  to  distribute  the  con¬ 
sumers  and  suppliers  as  well  as  to  fashion  their  implementation  for 
any  language  that  maps  to  CORBA  {e.g.»  Java  and  C++).  The  lan¬ 
guage  independence  is  obtained  by  specifying  interface  definitions 
via  CORBA ’s  IDL. 

However,  in  certain  usage  scenarios  where  distribution  and  multi¬ 
language  support  is  unnecessary,  the  use  of  CORBA  becomes  un¬ 
necessary.  As  described  in  Section  3,  there  are  important  examples 
of  this  case.  In  this  situation,  the  underlying  transport  mechanism 
can  be  a  simple  method  call,  doing  away  with  the  need  to  make  use 
of  an  ORB.  Indeed,  one  form  of  this  optimization  is  routinely  used 
in  the  Bold  Stroke  event  service,  in  the  form  of  the  Subscription 
and  Filtering  configuration  [12] 

Following  our  compositional  approach  [15],  we  sought  to  pro¬ 
vide  a  standard  interface  for  the  event  channel  while  making  the 
use  of  CORBA  optional  as  well.  In  other  words,  merely  by  se¬ 
lecting  an  EnableCorba  or  DisableCorba  feature  (which  are  mu¬ 
tually  exclusive  since  it  would  make  no  sense  to  enable  both)  at 
build-time,  it  should  be  possible  to  obtain  an  event  channel  with 
the  desired  configuration. 

In  what  follows,  we  describe  the  challenges  in  abstracting  the 
use  of  CORBA  in  the  event  channel  and  how  these  were  addressed 
by  the  use  of  AOP. 

5.2  CORBA  vs  No-CORBA 

Since  FACET  was  originally  designed  to  use  CORBA,  its  inter¬ 
faces  were  specified  in  CORBA  IDL  and  the  implementation  code 
was  written  in  terms  of  CORBA  Stub  and  Skeleton  classes  [20]. 
For  instance,  the  implementation  of  one  method  of  the  Suppli¬ 
er  Admin  interface  [22]  looked  like  this: 


public  class  SupplierAdminlmpl 
extends  SupplierAdminPOA  { 

//  Field  and  other  method  definitions 

public  ProxyPushConsumer  obtain_push_consumer () 

{ 

ProxyPushConsumer I mpl  ppclmpl  = 

new  Proxy PushConsumerlmpl  (eventChannel_) ; 

try  { 

org . omg . CORBA . Ob j  ec t  ob j  = 

poa_.servant_to_reference  (ppclmpl); 

ProxyPushConsumer  ppc  = 

Proxy PushConsumerHelper . narrow (obj ) ; 

return  ppc; 

}  catch  (Exception  se)  { 

//  Appropriate  code 

) 

return  null; 

} 

} 

It  is  clear  from  the  above  that  the  challenge  lies  in  separating  the 
concerns  related  to  CORBA*  from  the  actual  event  channel  imple¬ 
mentation  code  for  implementing  the  various  features  offered  by 
an  event  service  (present  in  various  other  classes).  In  the  follow¬ 
ing,  we  present  how  we  solved  this  problem  using  what  we  call  the 
“Placeholder”  pattern. 

5.3  Use  of  the  Placeholder  pattern 

Consider  the  ProxyPushConsumer  interface  [22]  of  the  event 
channel,  when  configured  to  push  structured  event  data.  In  the  case 
CORBA  is  in  use,  the  IDL  describing  this  interface  would  be : 

interface  PushConsumer  { 

void  push  (in  Event  data) ; 
void  disconnect_jpush_consumer  ()  ; 

}; 

interface  ProxyPushConsumer  :  PushConsumer  { 
void 

connect_push_supplier  (in  PushSupplier  supplier); 

}; 

The  IDL  compiler  when  given  the  above  would  generate  the 
necessary  Stub  and  Skeleton  classes  [20].  Now  to  implement  the 
ProxyPushConsumer  interface,  the  event  channel’s  implemen¬ 
tation  would  include  a  Proxy  PushConsumer  I  mpl  class  with 
the  following  definition: 

public  class  Proxy PushConsumerlmpl 

extends  ProxyPushConsumerPOA  { 

//  Appropriate  implementation 

} 

However,  in  the  case  CORBA  is  not  needed,  the  interfaces  can 
directly  be  specified  in  Java: 

public  interface  PushConsumer  { 

public  void  push  (Event  data) ; 

public  void  disconnect jpush_consumer  (); 

} 

public  interface  ProxyPushConsumer 
implements  PushConsumer  { 

public  void 

connect_push_supplier  (PushSupplier  supplier) ; 

} 


And  the  corresponding  implementation  of  the  ProxyPushCon¬ 
sumer  interface  would  be: 

public  class  ProxyPushConsumer Impl 

implements  ProxyPushConsumer  { 

//  Appropriate  implementation 

} 

This  idea  recurs  for  all  interfaces  exposed  by  the  event  chan¬ 
nel  and  is  a  concern  which  is  independent  of  the  manner  of  im¬ 
plementation.  To  address  this  issue,  we  make  use  of  what  we 
call  the  ’’Placeholder  Class”  pattern.  This  pattern  makes  use  of  a 
single,  empty  base  class  which  the  implementation  class  derives 
from  regardless  of  whether  the  event  channel  is  in  a  CORBA  or 
no-CORBA  configuration.  Aspects  then  modify  the  placeholder 
class  definition  to  derive  from  the  appropriate  base  class.  This  is 
demonstrated  in  the  following: 

public  class  ProxyPushConsumer Impl 

extends  ProxyPushConsumerBase  { 

//  Appropriate  implementation 

} 

aspect  EnableCorba  { 

declare  parents  : 

ProxyPushConsumerBase 

extends  ProxyPushConsumerPOA; 

//  Other  advice 

} 

aspect  DisableCorba  { 

declare  parents  : 

ProxyPushConsumerBase 

implements  ProxyPushConsumer; 

//  Other  advice 

} 

In  the  above,  the  ProxyPushConsumerBase  class  is  the  place¬ 
holder  class  that  the  aspects  modify  as  necessary,  to  either  extend 
the  ProxyPushConsumerPOA  class,  or  implement  the  Push- 
Consumer  interface. 

With  CORBA  enabled,  it  is  also  necessary  to  invoke  methods  on 
the  POA  [20]  object  to  obtain  a  reference  from  a  Servant  [20]  ob¬ 
ject.  For  example,  to  obtain  the  ProxyPushConsumer  interface 
reference  from  the  servant  ProxyPushConsumerlmpl  object, 
the  following  is  necessary: 

ProxyPushConsumer  ppc  = 

Proxy PushConsumerHelper .narrow  ( 
poa.servant_to_reference  (impl)); 

However,  in  the  no-CORBA  case,  to  obtain  the  interface  type  ref¬ 
erence,  the  following  is  sufficient  since  there  are  no  Servant  objects 
and  the  implementation  class  actually  implements  the  PushCon¬ 
sumer  interface  directly: 

ProxyPushConsumer  ppc  * 

( ProxyPushConsumer)  impl ; 

To  transparently  provide  the  correct  implementation  based  on  the 
configuration  of  the  event  channel  (i.e  CORBA  or  no-CORBA)  we 
make  use  of  what  we  call  the  “Placeholder  Method”  pattern.  This 
pattern  makes  use  of  a  single,  empty  method  for  each  such  opera¬ 
tion  which  is  then  advised  as  necessary  by  aspects.  For  instance, 
the  placeholder  method  in  this  case  would  be: 
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public  Proxy PushConsumer 

Get Proxy PushConsumerReference  < Proxy PushConsumerBase  impl) 

{ 

//  Nothing  needs  to  be  done  here 
return  null; 

) 

with  the  appropriate  code  weaved  in  via  around  advice  (which 
is  basically  an  alternate  method  implementation  for  the  method 
that  we  are  wrapping  around)  from  the  EnableCorba  and  Dis- 
abieCorba  aspects : 

aspect  EnableCorba  { 

Proxy PushConsumer  around  (...)  : 

Get Proxy PushConsumer Ref  (...) 

{ 

Pro^PushConsumer  ppc  » 

Proxy PushConsumerHe Iper . narrow  ( 

poa .  servant_to__ref  erence  ( impl ) )  ; 

return  ppc; 

} 

} 

aspect  DisableCorba  { 

Proxy PushConsumer  around  (...)  : 

Get Proxy PushConsumer Ref  (...) 

{ 

Proxy PushConsumer  ppc  = 

( Proxy PushConsumer )  impl ; 

return  ppc; 

} 

} 

The  advantage  of  such  an  approach  is  that  there  are  only  a  small 
number  of  public  interfaces  for  which  this  has  to  be  done  making 
it  suitable  for  any  application  which  needs  to  abstract  its  use  of 
CORBA  this  way. 

5.4  IDL  Generator  and  Build  Process 

When  different  features  are  enabled  in  FACET,  the  IDL  of  the 
event  channel  needs  to  change  accordingly  to  reflect  the  presence 
of  those  new  features,  in  the  case  CORBA  is  enabled  (there  is  no 
need  to  generate  IDL  when  CORBA  is  disabled).  In  previous  work, 
the  changes  to  the  IDL  of  the  event  channel  were  conducted  by 
the  use  of  scripts  which  makes  the  changes  using  primitive  text 
processing  and  search-and-replace  style  techniques  [15].  However, 
for  our  purposes,  using  such  a  script  would  entail  having  to  use 
different  aspects  for  the  cases  when  CORBA  is  enabled  and  when 
it  is  not.  From  a  software  engineering  standpoint,  this  would  be 
very  inefficient  and  greatly  reduce  the  maintainability  of  the  code. 

To  address  this,  we  chose  to  investigate  a  new  technique  which 
involves  the  generation  of  the  IDL  for  a  given  configuration  by 
reflection  on  the  classes  comprising  the  event  channel’s  interface. 
With  this,  it  is  only  necessary  to  specify  the  aspect  introductions  in 
the  Java  code  -  the  corresponding  changes  to  the  IDL  happen  auto¬ 
matically  since  the  mapping  from  CORBA  to  Java  is  well-known. 
The  generator  is  rurt  as  part  of  the  three-stage  build  process: 

•  Aspects  that  perform  introductions  are  applied  to  the  classes 
which  form  the  public  interface  of  the  event  channel 

•  The  IDL  Generator  reflects  on  these  classes  and  generates  the 
IDL.  The  IDL  compiler  is  then  run  to  generate  the  stub  and 
skeleton  classes.  In  the  case  CORBA  is  disabled,  this  step  is 
automatically  skipped. 

•  All  classes  comprising  the  event  channel  along  with  the  rel¬ 
evant  aspects  for  the  particular  feature  set  are  compiled  and 
the  relevant  jUnit  [7]  tests  are  run  [15]. 


The  IDL  Generator  we  have  developed  is  generic  in  its  imple¬ 
mentation  and  can  be  used  to  generate  the  IDL  interfaces  corre¬ 
sponding  to  any  set  of  Java  classes.  Conceivably,  this  technique 
can  be  extended  to  any  language  which  has  a  strong  runtime  type 
system  and  allows  reflection. 

6.  EXPERIMENTAL  RESULTS 

In  this  section,  we  present  results  that  we  obtained  in  estimating 
the  effect  that  CORBA  had  on  the  footprint  and  throughput  perfor¬ 
mance  of  FACET.  To  collect  such  data,  a  set  of  popular  configura¬ 
tions  was  identified  based  on  feedback  from  several  developers  of 
the  TAO  users  community  who  are  using  event  channels  in  their  ap¬ 
plication  development.  In  addition,  to  gauge  the  effect  of  individual 
features  on  the  overall  size  and  performance  of  the  FACET  event 
channel,  each  feature  was  studied  by  measuring  its  effect  across  all 
configurations  that  included  or  omitted  the  given  feature. 

One  method  to  measure  the  footprint  of  a  Java  application  is  to 
sum  the  size  of  all  the  .class  files  that  are  loaded.  Embedded 
systems  that  use  Java  interpreters  or  just-in-time  compilers  could 
use  this  metric  to  estimate  the  amount  of  RAM  needed-  Another 
method  consists  of  generating  native  code  using  a  compiler  (such  as 
GCJ  [10])  and  then  measuring  the  size  of  the  resulting  executable. 
The  compiled  code  is  more  suitable  for  comparisons  with  C  and 
C++  code.  Moreover,  embedded  real-time  applications  are  likely 
to  precompile  to  native  code  for  execution  predictability.  An  over¬ 
all  observation  has  been  that  the  size  of  the  GCJ  produced  object 
files  are  generally  larger  than  the  corresponding  .class  files  [1 6]. 
This  is  commensurate  with  the  design  of  .  class  files  to  be  small 
so  as  to  reduce  transmission  time  over  networks. 

Here,  we  report  results  based  on  .class  files  that  are  inter¬ 
preted  and  executed  using  the  Sun  Java  Virtual  Machine  (JVM) 
1 .4.0  with  Just-In-Time  compilation  enabled.  The  experiments  were 
performed  on  a  dual-Xeon  processor  machine  running  at  2.40  GHz, 
with  512  MB  of  RAM. 

With  Java  and  .class  files,  the  footprint  of  the  running  pro¬ 
gram  increases  as  classes  are  loaded.  We  report  the  maximum  foot¬ 
print,  achieved  when  all  code  has  been  loaded;  such  measurements 
are  most  appropriate  for  an  embedded  system.  For  a  native-code 
compiled  version,  both  the  footprint  and  the  resulting  throughput 
are  expected  to  increase. 

6.1  Common  Configurations 

The  following  are  the  10  event  channel  configurations  used  in 
collecting  experimental  data : 

1 .  Configuration  1  (Base):  Although  the  applications  requested 
by  developers  all  required  more  functionality  than  the  base, 
it  is  useful  in  that  it  is  a  lower  bound  on  the  footprint.  Note 
that  all  subsequent  tests  use  the  full  functionality  provided 
by  the  base. 

2.  Configuration  2:  Several  developers  only  needed  configu¬ 
rations  similar  to  the  standard  CORBA  COS  Event  Service 
specification.  This  configuration  has  CORBA  Any  payloads 
and  does  not  support  filtering.  The  pull  interfaces  were  not 
included  in  this  configuration  since  they  were  not  used. 

3.  Configuration  3:  This  configuration  is  the  same  as  the  previ¬ 
ous  except  that  the  tracing  feature  is  enabled. 

4.  Configuration  4:  Structured  events  and  event  sets  are  en¬ 
abled.  This  configuration  also  adds  the  time  to  live  (TTL) 
field  processing  to  eliminate  loops  created  by  federating  event 
channels.  This  configuration  is  still  minimal,  however,  and 
does  not  support  any  kind  of  event  filtering. 
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5.  Configuration  5:  This  configuration  has  support  for  dispatch¬ 
ing  events  based  on  event  type.  It  uses  a  CORBA  octet  se¬ 
quence  as  the  payload  type  and  is  a  common  optimization 
over  using  a  CORBA  Any.  This  configuration  is  similar  to 
that  used  in  the  TAO  Real-Time  Event  Channel  (RTEC). 

6.  Configuration  6:  This  configuration  adds  support  for  the  event 
pull  interfaces  to  configuration  5  and  uses  a  CORBA  Any  as 
the  payload. 

7.  Configuration  7:  This  configuration  enhances  configuration 
5  by  replacing  the  simple  event  type  dispatch  feature  with  the 
event  correlation  feature.  In  the  corresponding  application, 
event  timestamp  information  was  also  needed,  but  the  event 
pull  feature  was  not. 

8.  Configuration  8:  This  configuration  represents  one  of  the 
largest  realistic  configurations  of  FACET.  It  supports  the  pull 
interfaces,  uses  event  correlation,  and  adds  support  for  statis¬ 
tics  collection  and  reporting.  It  uses  structured  events  car¬ 
rying  CORBA  Any  payloads  and  headers  with  all  possible 
fields  enabled. 

9.  Configuration  9:  This  configuration  adds  the  tracing  feature 
to  configuration  8. 

1 0.  Configuration  10:  This  configuration  is  representative  of  that 
used  in  the  Boeing  Bold  Stroke  architecture.  It  includes  a 
number  of  features  like  type  filtering,  event  correlation,  event 
timestamps  and  the  real  time  dispatcher  feature,  a  feature  that 
allows  consumers  and  suppliers  to  set  real-time  priorities  on 
event  delivery. 

6.2  Footprint  Measurements 

As  shown  in  Figure  3,  the  base  FACET  configuration  (config 
1)  is  3  times  larger  when  CORBA  is  present:  166,921  bytes  with 
CORBA  and  55,250  without. 

At  the  other  extreme,  one  of  the  fuller-featured  FACET  configu¬ 
rations  (config  9)  has  a  size  of  475,100  bytes  with  CORBA  and  a 
size  of 342,226  bytes  without  —  approximately  1 .4  times  larger  for 
CORBA,  This  is  expected  since  there  are  a  significant  number  of 
Stub  and  Skeleton  classes  that  are  generated  by  the  IDL  compiler, 
which  are  absent  in  the  no-CORBA  case. 

It  must  be  noted  that  the  size  of  the  ORB  has  not  been  included 
in  this  study.  It  follows  that  if  it  were  indeed  included  in  these  mea¬ 
surements,  there  would  be  an  even  bigger  difference  in  the  footprint 
observed.  Generally,  in  full-featured  ORBs  such  as  JacORB  [3] 
that  are  not  subsettable,  the  most  casual  reference  to  the  ORB  causes 
the  entire  ORB  to  be  included  in  the  resulting  executable  code. 
While  ORBs  vary  in  size  [9],  and  some  ORBs  do  offer  reduced- 
feature  versions,  the  choice  of  which  features  to  include  or  omit  is 
not  made  on  an  application-specific  basis.  Conceivably,  our  AOP 
approach  for  including  features  in  an  event  channel  could  be  ex¬ 
tended  to  include  only  those  ORB  features  needed  to  support  a 
given  event-channel  configuration. 

Figure  3  shows  that  the  disabling  of  CORBA  for  the  configu¬ 
rations  we  considered  mostly  reduced  footprint  by  about  half  — 
appreciable  savings  for  small  embedded  systems. 

6.3  Throughput  Measurements 

Figure  4  shows  the  difference  in  throughput  performance  with 
and  without  CORBA.  When  configured  as  the  standard  CORBA 
COS  Event  Service  [22],  the  throughput  with  CORBA  enabled  was 
1651  events/sec  as  compared  with  131,758  events/sec  without  — 
a  difference  of  2  orders  of  magnitude!  This  can  be  explained  by 
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Figure  3:  FACET  footprint  under  different  configurations 


Figure  4:  Throughput  under  different  configurations 


the  fact  that  the  Java  ORB,  JacORB,  does  not  include  optimiza¬ 
tions  for  collocated  objects  which  means  that  the  Stubs  and  Skele¬ 
tons  perform  marshalling  and  communication  over  network  sock¬ 
ets  assuming  a  truly  distributed  system.  With  an  ORB  such  as  TAO 
that  does  include  such  optimizations,  the  performance  difference  is 
likely  to  be  less  dramatic  but  still  substantial. 

This  level  of  improvement  without  CORBA  held  for  all  config¬ 
urations  of  the  event  channel  that  we  studied  with  the  exception 
of  configurations  which  included  the  tracing  feature  (configs  3  and 
9).  The  reason  for  this  can  be  attributed  to  the  enormous  amount  of 
code  weaved  in  by  the  Aspect!  compiler  onto  all  the  methods  of  ev¬ 
ery  class  in  the  event  channel,  when  the  tracing  feature  is  enabled. 
The  overhead  of  these  extraneous  method  calls  to  the  log4j  [1] 
logging  library  contribute  significantly  to  performance  degradation 
and  to  the  size  of  the  footprint.  This  observation  is  consistent  with 
findings  in  a  previous  study  [16]. 

6.4  By-Feature  Study 

We  next  measured  footprint  and  throughput  for  various  configu¬ 
rations  in  which  only  a  single  feature  (and  features  upon  which  it 
depends)  was  enabled  at  a  time.  This  experiment  quantifies  the  the 
size  contribution  and  throughput  degradation  of  a  given  feature. 

Figure  5  shows  footprint  reduction  by-feature,  with  and  without 
CORBA.  For  an  embedded  system,  even  modest  savings  can  be 
crucial  to  a  component’s  cost. 

A  much  greater  impact  can  be  seen  as  we  study  performance.  As 
shown  in  Figure  6,  the  difference  for  each  feature  with  and  without 
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Figure  5:  Impact  of  different  features  on  footprint 


Figure  6:  Impact  of  different  features  on  throughput 

CORBA  is  dramatic.  The  interesting  observation  is  that  no  differ¬ 
ence  is  observed  among  the  features  when  CORBA  is  disabled.  An 
explanation  for  this  is  that  the  aggregation  of  features  on  the  base 
and  the  overhead  associated  with  the  code  weaved  in  by  the  As¬ 
pect!  compiler  is  negligible,so  that  the  throughput  at  this  point  is 
limited  by  the  operating  system  and/or  hardware.  This  indicates 
that  the  throughput  performance  of  the  event  channel  with  CORBA 
disabled  is  at  a  maximum  and  is  quite  unaffected  by  the  feature  set 
(again  with  the  exception  of  the  tracing  feature). 

It  can  be  argued  that  a  true  measure  of  the  average  effect  of  a 
feature  on  the  footprint  and  throughput  of  the  event  channel  can 
be  obtained  by  measuring  the  overhead  over  the  set  of  all  possible 
valid  combinations  that  differ  by  that  one  feature  [16].  We  plan  to 
investigate  this  line  of  experimentation  in  future  work.  However, 
when  the  number  of  features  is  large  as  is  the  case  in  FACET’S 
current  code  base,  the  number  of  valid  combinations  make  it  quite 
impractical  to  run  through  each  one  of  them.  In  such  cases,  a  more 
intelligent  method  of  grouping  features  is  necessary. 

7.  FUTURE  WORK  AND  CONCLUDING  RE¬ 
MARKS 

As  embedded  software  continues  to  grow  more  complex  and  par¬ 
ticipate  even  more  in  distributed  systems,  the  need  to  use  standard 
middleware  becomes  even  more  imperative.  While  frameworks 
such  as  ACE  and  TAO  do  reasonably  given  the  constraints  of  em¬ 
bedded  systems  and  meet  the  needs  of  existing  large-scale  embed¬ 


ded  systems,  small-scale  embedded  systems  need  more  and  the  use 
of  AOP  does  seem  promising. 

While  significant  advances  have  been  made  in  subsetting  middle¬ 
ware,  with  a  precise  control  over  footprint  and  feature  set,  the  use 
of  transport  mechanisms  such  as  CORBA  is  redundant  in  scenar¬ 
ios  where  objects  are  collocated  and  written  in  the  same  language. 
Building  on  known  AOP  techniques,  we  have  abstracted  the  trans¬ 
port  layer  of  the  FACET  event  channel  such  that  use  of  CORBA 
can  be  specified  at  build-time  thus  providing  full-customization  of 
an  event  channel  for  a  particular  application.  In  this  paper,  we  have 
presented  the  results  of  the  measurement  of  the  impact  of  CORBA 
on  the  footprint  and  throughput  of  the  event  channel  for  popular 
event  service  configurations  presently  in  use  by  members  of  the 
TAO  user  community. 

As  future  work,  we  intend  to  take  the  transport  layer  abstrac¬ 
tion  further  and  to  support  other  transport  mechanisms  such  as  Java 
RMI  [27]  through  encapsulation  in  a  feature.  We  are  also  investi¬ 
gating  extending  FACET  to  make  real-time  guarantees  about  event 
delivery.  And  finally,  we  are  studying  the  design  patterns  involved 
in  building  such  customizable  middleware  embedded  systems. 
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